HPAVC/HPAVC CD-ROM.iso/pc/BOBOLI.ZIP/SRC/README.TXT

Text File | 1996-06-06 | 7.7 KB | 135 lines

BOBOLI THE MIGHTY KNIGHT
By Mike Hommel

  If you want help on playing the game, see BOBOLI.DOC.

This software and all the accompanying goods are supplied AS-IS.  They may
blow up your computer for all I know, and it's not my fault if they do.  You
may do whatever the hell you want with this stuff.  But it would be nice if
you didn't try to claim it as your own, because then everybody would laugh at
you, and you don't want that.

  The source is included, in the \SRC subdirectory, oddly enough, and it is
approximately devoid of comments.  You won't get much from looking at it -
sorry, but I didn't really intend this as a lesson in game programming (good
thing, since it really represents a lot of the worst things you can do when
programming).  But the header files are pretty legible (of course I would
think that, I wrote them).  I think GUYS.H is kind of an interesting concept.
It's sort of a script file defining the various characters in the game.  It
should be fairly self explanatory.  Well, not really.  But I tried!
  Known problems: it will crash occasionally citing an interrupt 0x22 (my PC
programming book calls that the Terminate Program interrupt, and terminate it
does), or sometimes just freeze up.  I am pretty much sure that these are a
result of my very poorly written keyboard handler and timer handler.  I just
do NOT get all that __dpmi_stick_stuff_onto_my_procedure() stuff at all.  The
FAQ explains it, but I'm too stupid to follow it.  I need examples.  Anyone
is welcome to fix this problem (also, apparently on SOME faster computers,
the keyboard handler 'sticks' badly - not on any of the ones I've tried, but
my friend claims he has seen it on every computer he tried.  I think this is
also a result of the same problem), and PLEASE send me a copy of the fixes.
I am very used to the syntax of my kb handler, and would hate to have to use
someone else's idea of easy-to-use.
  Also problem: The golems.  They are just too damn stupid to live.  It really
bugs me when they start punching the floor.  It almost gives them a bit of
personality, but not quite.  I am not sure why they are so moronic, but it
probably has a lot to do with the fact that I just threw in the golem stuff at
the last minute, and it really only consists of a few if(kind==golem)
statements.
  Aside from that, it seems pretty perfect (well, bug-free anyway, I wouldn't
call it perfect).  If you want to modify the networkiness to support some real
type of network (or maybe just a standard modem, which wouldn't be too tough,
I think), you can look for all the calls to the functions listed in com.h
(there are only about 3 functions!), and replace them with your own.

Some stuff about the libraries:

  These are the libraries I use for everything.  Boy I love my libraries.  I
will probably do away with UMKs in favor of something that stores runs of
pixels for speed for my next game though.  It is awfully wasteful, speedwise,
for me to do what I am doing now.  Anyway, here's info about each library:

mgraph: the core library.  Basic graphics stuff.  Screen copying, palettes,
        the usual.  It also defines what a 'byte' is and what a 'word' is.
umk: UMK stands for, egotistically enough, UltraMikon.  They are my sprites.
     They are stored as an array of 256 of:
       width(byte... I think? no, probably a word)
       height (same deal)
       size of data (word)
       image data... just straight pixels, except when a 0 is encountered, it
         is followed by a run count.  So transparency is RLE'd.

     there are about a billion different draw functions in here, see them all
     in umk.h.  Some are a bit tough to comprehend by the name.  Feel free to
     ask, if you care.
timer: the timer library.  VERY simple stuff, and as I mentioned earlier,
       buggy.
mkey: keyboard handler.  Also quite simple, and also buggy.
mfont: font handler.  It's only got one font, and it only handles 6x6 fonts.
       It does very little, but it does all I need.
com: A VERY simple com-port driver.  Sends and receives bytes over the com
     port.  Based very much on Samuel Vincent's svasync library.  If you
     want some high-quality com stuff, THAT's what you need.  It's called
     SVASYNC.ZIP, and you can probably find it at any handy djgpp programming
     site.  It handles interrupt driven transmission, which mine definitely
     does not, and it is FAR more robust and versatile than mine (and
     supports UARTs with FIFO abilities, and so on and so on).

SVASYNC can be found at:
  http://www.delorie.com/djgpp/dl/contrib/svasync.zip

  I also have an mflic library if anybody wants some real simple .FLI code.
I mean REAL simple.  But it works, and it's fast(-ish).

Miscellaneous stuff that I can think of:

  This program uses the __djgpp_nearptr_enable() dealie.  I hear that's bad,
but if the worst thing it can do is make my computer crash if I have a bad
pointer, then fine.  I deserve that if I have a bad pointer.

  the \CTR subdirectory contains, conveniently, *.CTR files.  They are just
lists of x,y pairs (signed bytes) which are used to offset the drawing
position of the UMK to which they refer, in order to center it.  For instance,
BOBOLI.CTR contains 256 coordinate pairs which refer to the 256 UMKs in
BOBOLI.UMK, so that I call umk_draw like this:

  for(n=0;n<256;n++)
    umk_draw(xpos-bobctr[n].x,ypos-bobctr[n].y,bobumk[n],screen);

  and it will draw all the frames of Boboli in order, centered at xpos, ypos.
Note that this is not a true center, it is an arbitrary point I picked, in
this case, it is right between his feet.  This is the point that I want to use
logically as his 'center', since he is vaguely 3d and not a strictly top-view
character.  Then, in the game I can refer to xpos and ypos as his coordinates
for purposes of checking which tile he is in, etc.

  The tile graphics should be in a library.  I seem to use them a lot, but
there is always some new twist to them that means I must write new routines
for them.  In this case, the twist was that I decided I didn't want to clip
them, so I made a virtual screen 256x256 (which is a cool idea, for many
reasons, not the least of which is the nifty pixel addressing: x+(y<<8)), and
draw the tiles to that, and then had to make a scrcpy which copies from that
kind of screen to a 320x200 one.
  Speaking of the tiles, there should be a ton more of them.  That map is just
plain BORING.  Speaking of THAT, the map is boring, feel free to enhance it
drastically.  Just don't forget to leave walls all around the edges.  I think
it is undefined what projectiles do if they leave the map (yow, maybe I
shouldn't have left that part where there is water right up to the edge!).

  The \UMK directory contains all the umks, and the \PCX directory is rather
obvious.  The stuff in the \MISC directory is:
  LITTLE.FNT: the font file for my adorable 6x6 font
  DARK.MAT: 256 bytes - pointers into my standard palette denoting what
            color to go to from each color if you want it to be darker.
            (explanation: if color 4 is blue and color 8 is dark blue,
                          the fourth byte of this file would be 8.  Get it?)
  HULK.PAL: There's a good reason why it is named this, but this is my usual
            palette, 16 shades of 16 colors (massive waste of space: there
            are 16 true blacks and 16 true whites!).

  That's about it.  Questions/comments are welcome to [e-mail].
However, suggestions on what could be added to the game are NOT welcome -
this game is DONE.  If you want to add something, go ahead, it's out of my
hands.
  By the way, there's no ending- you can keep playing even after you kill the
wizard, so don't start whining about how it refuses to end once he's dead.